feat(web): real Tools, Rooms, and Permissions panels on agent detail - #104
Conversation
Those tabs were removed in #101 because they silently rendered Overview and the data was not exposed. This adds the API layer and brings them back backed entirely by stored state. New GET /api/v1/agents/[id]/profile (agents.read) returns: - Tools: the declared envelope joined with what the agent has actually called, from agent_tool_calls through its own runs. Registry metadata marks each tool read-only or mutating and names its approval action. Tools called but no longer declared are surfaced rather than hidden — a call outside the envelope is exactly what an operator needs to see, as is a declared tool the runtime registry does not implement. - Rooms: allow-listed rooms and real memberships, with Slack exposure per installation. The two disagreeing is shown, not reconciled. - Permissions: declared requirements against actual grants. 'missing' is the governance-critical one — an agent required to hold a capability it does not have fails at run time, and nothing else in the product surfaced that. 'surplus' supports least-privilege review; 'unknown' catches requirements that are not capabilities at all. The panels are strictly read-only. Grants and allow-lists stay server-controlled, and a test asserts the UI has no mutation path. Instructions, Runs, Evaluations, Versions, and Audit remain unbuilt and stay absent rather than falling through to Overview. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 22 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Task 17. Follows #101, which removed these tabs because they silently rendered Overview and the underlying data was never exposed. This adds the API layer and brings them back backed entirely by stored state.
New API
GET /api/v1/agents/[id]/profile— requiresagents.read, organisation-scoped on every read.Tools
The declared envelope joined with what the agent has actually called, aggregated from
agent_tool_callsthrough that agent's own runs. Registry metadata fromagentToolRegistrymarks each tool read-only or mutating and names its approval action.Two disagreements are surfaced rather than hidden, because both matter:
unregistered.Rooms
Allow-listed rooms and real membership rows, plus Slack exposure per installation. Where the allow-list and actual membership disagree, the panel says so rather than quietly reconciling them.
Permissions
Declared requirements against actual grants:
missing— required but not held. This is the governance-critical one: a run touching such a capability fails with a capability error, and nothing else in the product surfaced it. Rendered as an alert, not a list item.surplus— held beyond the declaration, for least-privilege review.unknown— declared requirements that are not capabilities this build knows about. This is the same class of drift that hidagents.handoffandbrolga.context.readearlier in this series.Execution ceilings (runtime, tokens, cost) are shown alongside, since they are the other half of what bounds a run.
Read-only by construction
Grants and allow-lists stay server-controlled. A test asserts the panel file contains no
apiPostand nouseMutation, so a future edit cannot quietly turn a governance view into a grant surface.Still unbuilt
Instructions, Runs, Evaluations, Versions, and Audit remain absent rather than falling through to Overview. Runs and Audit are the most tractable next — both have APIs already.
🤖 Generated with Claude Code